Allow VertxHttpClientBuilder to be seeded with a base WebClientOptions object, allowing more customization of the Vertx HTTP Client #7315
Conversation
capistrant
requested review from
manusa,
oscerd,
rohanKanojia and
shawkins
as code owners
did that just now. Was working on running it a bit in local k8s env and noodling on how we could actually test that the configs are getting applied. Especially in the sense of not having it regress in future and quietly stop taking effect. Running in dev, I did a little bit on Friday and will do some more today. The testing strategy, I'm still stumped on |
Actually I see there is something we originally missed. The VertxHttpClientFactory.additionalConfig method should be called by VertxHttpClientBuilder.build method. That is consistent with the fabric8 factories and somewhat redundant with the ability to pass in a WebClientOptions. If you wire in that method, you should be able to check that your passed in options is in use. I'm not opposed to having both ways of handling the WebClientOptions as subclassing is probably less obvious than looking for a builder method. cc @manusa |
#7252 did talk about this as an alternative I considered. The reason I did not propose it was to avoid proposing what would be a breaking change for folks not using the default factory. That is at least how I interpreted the change, that it could be breaking. If that is ok, I could pursue that instead. It does make the most sense in terms of keeping patterns consistent across the project |
2 participants
Description
fixes #7252
Allows user to seed the Vert.x Http Client Builder with a custom WebOptions object if they want to modify configs of this object. As the issue specs out, this is not the most ideal solution, I think using additionalConfig like the other HttpClient implementations do would be best. But that seems like a breaking change since it would be more invasive.
Type of change
test, version modification, documentation, etc.)
Checklist